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(57) ABSTRACT 

An apparatus, method and system are provided for an 
intermediate reliability protocol for network message trans- 
mission and reception, and are particularly suited for real 
lime applications, such as internet telephony. The preferred 
system embodiment includes a plurality of servers, con- 
nected to each other over a plurality of networks, such as 
over two ethemets. A first server, when operative, includes 
program instructions to transmit a message. A second server, 
which is coupled to the first server over the networks, when 
operative, includes program instructions to receive the mes- 
sage. Under typical circumstances, the received message 
will be delivered locally on the second server, to a desig- 
nated local process. Under other circumstances, the second 
server will resynchrooize to the received message, dropping 
stored messages and avoiding further delay in message 
delivery. For such resynchronization, when the received 
message has a sequence number which is out of sequence, 
the second server has further instructions, first, to determine 
whether a reset bit is set and, when the reset bit is set, to 
resynchronize to the received message; second, to determine 
whether the first server is inactive and, when the first server 
is inactive, to resynchronize to the received message; and 
third, to determine whether a predetermined number of 
transmit reject messages have been transmitted to the first 
server and, when the predetermined number of transmit 
reject messages have been transmitted to the first server, to 
resynchronize to the received message. 

94 Claims, 9 Drawing Sheets 
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FIG. 5 A 
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FIG. 5B 
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FIG. 5C 
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FIG. 6 
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APPARATUS, METHOD AND SYSTEM FOR reasonable assurance of message delivery, and having timely 

AN INTERMEDIATE RELIABILITY delivery with low delay characteristics, evSpecially suited for 

PROTOCOL FOR NETWORK MESSAGE real-time applications such as inter^system communication 

TRANSMISSION AND RECEPTION ^ between telephony applications. Resynchronizations 

5 may occur to avoid undue delays in message transmission 

FIELD OF THE INVENTION and reception, while messages may be buffered or stored to 

^ . . , . ^ . . reduce message loss. Such resynchronization, including 

The present invention relates in general to communication ^^^^ ^^^^^^ ^^^^^^ ^ ^^^^^ ^^t)ers, occurs 

system protocols, and more parUoilarly, to an apparatus ^^^^ ^^^^^^ ^ maintained as up and vaUd, with 

method and system for an mtermediate rehabihty protocol ^^^^^^^ communication, rather than with the prior art loss 

for network message transmission and reception. ^i^^ connection 

BACKGROUND OF THE INVENllON Potential hardware failures in the network are detected 

automatically, such as the loss of an cthemct, with trafi&c 

Various communication system protocols have evolved correspondingly re-routed. In addition, the apparatus, 

both having varying degrees of reliability and having vary- nj^t^od and system of the present invention may be imple- 

ing delay or timeliness charactenstics. In general, those mented in a cost-effective fashion into existing telecommu- 

protocols having very high reliability, virtually guaranteeing ^5^^,^^^^ ^y^j^j^^ networks, and may be implemented as 

the amval of a data packet at its specified destination, an upper level protocol on top of existing protocols such as 

generally have high delay characteristics. For example, the UDP/IP 

X.25 protocol provides guaranteed dcliveiy of every mes- ^^^^^^^^ ^ embodiment includes a plurality of 

sage transmitted, but such guaranteed dehvery may occur servers, connected to each other over a plurality of networks, 

over a longer period of Ume than desirable or preferable for ^^^^ ^^^^ ^^^^^^^^^ ^ g^^^ ^ ^^^^ operative, 

real time applications For example, for telephony, mforma- ^^^i^^^^ ^ instructions to transmit a message. A 

tion that IS delayed by more than a few seconds, or even ^^^^^^ ^^^^^^ ^^^^^ ^ ^^^^^ ^^^^ 

one-half second, is typically no longer required, and has networks, when operative, includes program instructions to 

become useless and irrelevant to real time voice commum- ^^^^.^^ ^ ^^^^ -^^ circumstances, the 

cations Similarly, other protocols such as TCP/IP also have ^^^^-^^^ deUvered locally on the second 

high rehability characterisucs with correspondmgly high ^ ^ designated local process. Under other 

delay charactenstics, and accordingly also may be mappro- circumstances, the second server wiU resynchronize to the 

pnate for real time applications. ^^^^.^^^ message, dropping stored messages and avoiding 

Conversely, protocols such as UDP/IP, without such high further delay in message delivery. For such 

reliabihty, are generally excessively lossy for such real time resynchronization, when the received message has a 

applications, such as telephony. In such protocols, messages sequence number which is out of sequence, the second 

are frequently lost, and many real time situations and server has further instructions, first, to determine whether a 

applications require a higher degree of reliability. reset bit is set and, when the reset bit is set, to resynchronize 

Voice telecommunications and other real time to the received message; second, to determine whether the 

applications, as a consequence, have different timing and first server is inactive and, when the first server is inactive, 

reliability requirements than more typical or general internet to resynchronize to the received message; and third, to 

applications. Typical internet appKcations such as electronic determine whether a predetermined number of transmit 

mail have a guaranteed delivery, but a timing delay in the reject messages have been transmitted to the first server and, 

delivery is not very important. With real time appHcaUons when the predetermined number of transmit reject messages 

such as telephony, however, timing and other delay issues have been transmitted to the first server, to resynchronize to 

arc very important, while the occasional loss of a message the received message. 

under heavy traffic circumstances is considered relatively in the various embodiments, such resynchronization 
acceptable or normal. 45 includes resynchronizing to the sequence number of the 

A connection oriented protocol is also not desirable or currently received message, and clearing receive buffers in 

preferable for such real time applications, because the total a shared memory of the second server. The second server has 

number of connections in a complex telephony system could further instructions to maintain the state of the protocol as 

be very high. In addition, various high reliability systems valid with the first server during such resynchronization. In 
achieve that reliability by redirecting traffic when a hard- 50 addition, when the received message has a sequence number 

ware node is unavailable and, for a telephony system, which is out of sequence, the second server will buffer the 

reestablishing such connections is highly undesirable. received message in a shared memory, and will transmit a 

As a consequence, a need remains for a protocol having reject message to the first server, requesting a retransmission 

an intermediate level of reliability, having reasonable or of outstanding or missed messages. 

acceptable assurance that messages are delivered, while 55 Potential hardware failures are detected, in the preferred 

simultaneously providing sufi&ciently timely delivery to system embodiment, when a message has not been received 

meet the requirements of real time applications. Such a from the first server during a first predetermined period of 

protocol should be able to buffer messages to reduce mes- time, and under such circumstances, the second server has 

sage loss, and should be able to detect hardware failures in further instructions to transmit a first connectivity message 

the network and reroute traffic around them. In addition, 60 to the first server over a first network of the plurality of 

such an apparatus, method and system should be capable of networks, such as a first ethemet. If and when a response 

implementation in a cost-effective fashion into existing message has not been received from the first server during 

telecommunication systems and networks. a second predetermined period of time, the second server has 

cIT^>f^)^ Aov nrr ™c rvrx/cKmriNT further instructions to transmit a second connecUvity mes- 

SUMMARY OF THE INVENTION ^^^^ ^^^^ ^^^^ ^ ^^^^ ^^^^^^^ p^^^^^.^^ 

The apparatus, method and system of the present inven- of networics, such as a second ethernet. If and when a 

tion provide an intermediate reliability protocol, having response message has not been received from the first server 
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duriag a third predetermined period of time, the second son able and desirable performance for real-time 

server has further instructions to set a status of the first applications, such as voice communications. A particularly 

server as inactive, and to clear all transmit buffers and aU significant advantage of the various embodiments is the 

receive buffers, in a shared memory of the second server, provision of such reasonable reliability while simulta- 

pertaining to the first server. 5 neously providing timely delivery of messages, reducing or 

Numerous other advantages and features of the present ^^^^^^^^ delays in message transmission and reception, 

invention will become readily apparent from the following TJe vanous emboditnents of the present mventionaccom- 

. . r *u • J *u u J- 4 plish this result through a umque integration of different or 

detailed descnption of the invention and the embodiments ^. . j r ■ * • • j 

. „ „ ,f , . jr.. J divergent methods of managing message transmission and 

thereof, from the claims and from the accompanying draw- ^^^^^^.^^ ^ reasonably high kvel of reUability, 

the various embodiments track message transmission and 

BRIEF DESCRIPTION OF THE DRAWINGS reception, and buffer messages to reduce potential message 

loss, maintaining transmit buffers for unacknowledged mes- 

FiG. 1 is a block diagram illustrating a system embodi- sages and maintaining receive buffers for out of sequence 

ment in accordance with the present invention; messages. To provide for sufiBciently timely delivery for real 

FIG. 2 is a block diagram illustrating in greater detail a time applications, however, in the event such message 

system embodiment in accordance with the present inven- tracking is or may be creating undesirable delays, the 

tion; protocol will resynchronize. Such resynchronization 

FIG. 3 is a block diagram illustrating various apparatus involves a determination that for real time applications, it is 

embodiments in accordance with the present invention; 20 ^^^^ significant to be current than to be perfectly reliable. 

FIG, 4 is a flow diagram illustrating a transmission ^ I consequence, messages which may be older than 

portion of a method embodiment in accordance with the one-haff second to two seconds are considered to have 

nresent invention* become irrelevant and are dropped, with the protocol resyn- 

™_ Ml . ' ^- f chronizing to whatever message is then current. Also as a 

FIG. 5 IS a flow diagram illustraung a receive portion of .^^^J departure from the prior art, such resynchroni- 

a method embodiment m accordance with the pn^seot inven- « ^^^.^^ performed while the protocol is maintained as up 

and valid (rather than dropped or torn down connection), 

FIG. 6 is a flow diagram illustrating a reject state portion ^^ti communication continuing during such resynchroniza- 

of a method embodiment in accordance with the present ^^j^ addition, also as discussed in greater detail below, 

invention; and jjje various embodiments provide a means to automaticaUy 

FIG. 7 is a flow diagram illustrating a connectivity state switch between two different networks (ethemets), to auto- 

portion of a method embodiment in accordance with the maticaUy re-route messages in the event of a hardware 

present invention. failure. 

DETAILED DESCRIPTION OF THE FIG. 1 is a bloc^ diagram illustrating a network 105 

INVENTION ■^^ havmg a system embodiment 100 or the present invention. 

As illustrated in FIG. 1, the network 105 includes one or 

While the present invention is susceptible of embodiment more switches 110, connected or coupled via signaling links 
in many different forms, there are shown in the drawings and 140 to the public switched telephone network ("PSTN") 115 
will be described herein in detail specific embodiments and to various other nodes, such as signal transfer points 
thereof, with the understanding that the present disclosure is 40 ("STPs") 120. The STPs 120 are, in turn, coupled via 
to be considered as an exemphficalion of the principles of signaling links 140 to other network nodes, such as to 
the invention and is not intended to limit the invention to the service control points ("SCPs") 100, and to other nodes such 
specific embodiments illustrated. as a service node ("SN") 130 connected to a mobile switch- 
As mentioned above, a need remains for a protocol having ing center 125. In the preferred embodiment, the apparatus, 
an intermediate level of reliability, having reasonable or 45 method and system of the present invention are contained in 
acceptable assurance that messages are dehvered, while the network nodes referred to as service control points 100. 
simultaneously providing sufificienfly timely delivery to Alternatively, the apparatus, method and system of the 
meet the requirements of real time applications. The present invention may be contained with any other network 
apparatus, method and system of the present invention node. 

provide such an intermediate reliability protocol, having 50 The service control points 100 are also linked via various 

reasonable assurance of message delivery, and having timely communication (or signaling) links, such as data links, to 

delivery. In accordance with the present invention, messages various data interfaces 135, such as TCP/IP or X.25 

may be buffered or stored to reduce message loss, and interfaces, for providing various network or customer ser- 

hardware failures in the network are detected with traffic vices. The various signaling links 140 may be any of a 

rerouted around them. In addition, the apparatus, method 55 plurality of communication channels or liriks, such as sig- 

and system of the present invention may be implemented in nailing system 7 links, data links, or various trunking 

a cost-effective fashion into existing telecommunication channels. 

systems and networks, and may be implemented as an upper Within this network 105, a wide variety of messages and 

level protocol on top of existing protocols such as UDP/IP. message types may be transmitted between and among the 

As discussed in greater detail below, the various embodi- 60 various nodes, which are designed to provide intelligent 

ments of the present invention provides an "intermediate" network services. For example, upon the request of a switch 

level of reliability, coupled with timely delivery, which is 110, the various SCPs 100 may provide call handhng 

significantly different than other systems and protocols instructions for the switch 110, while a service node 130 

utilized for message transmission and reception. In accor- may provide automatic speech recognition capability. With 

dance with the present invention, a level of reliability is 65 regard to the present invention, the network 105 is only 

provided which is not absolutely guaranteed, on the one required to be capable of transmitting and receiving 

hand, but nonetheless provides sufficient reliability for rea- messages, of any kind, between and among the various 
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nodes, such as a switch 110, an STP 120, or an SCP 100. As Contimiing to refer to FIG. 3, the various processors, such 

indicated above, the messages may be of any substantive as processors 250, may include a single integrated circuit 

type or kind, such as caller ID messages, calling name ("IC"), or may include a plurality of integrated circuits or 

messages, call routing information, advanced call routing other components connected, arranged or grouped together, 

information (such as toll-free routing), account card calling, s such as microprocessors, digital signal proccvssors ("DSPs"), 

local number portability, personal numbers, and mass call- application specific integrated circuits ("ASICs"), assod- 

ing. ated memory (such as RAM and ROM), and other ICs and 

FIG. 2 is a block diagram illustrating, in greater detail, a components. As a consequence, as used herein, the term 

system embodiment 200 in accordance with the present processor should be understood to equivalenUy mean and 

invention. As mentioned above, the system 200 is preferably include a single processor, an arrangement of processors, 

embodied within a service control point 100 or other node microprocessors, controllers, or some other grouping of 

within a network 105, providing intelligent network services integrated circuits which perform the fimctions discussed in 

as a database server. Referring to FIG. 2, the preferred detail below with reference to FIGS. 4 through 7, with 

system 200 includes one or more control servers 230 and one associated memory, such as microprocessor memory or 

or more telecommunication servers 210, which are, additional RAM, ROM, EPROM or E^PROM. The meth- 

respectively, all connected to each other over one or more odology of the invention, as discussed below with reference 

ethernets 220. to FIGS. 4 through 7, may be programmed and stored in the 

As discussed in greater detail below, in the preferred processors 250, with their associated memory and other 

system embodiment 200, one of the control servers 230 is equivalent components, as a set of program instructions for 

maintained in an active mode, while the other control server ^ subsequent execution when these processors 250 are opera- 

230 is mamtained in a standby mode. In addition, each of the tive (i.e., powered on and functioning), 

telecommunication servers 210 may communicate with each The shared memories 240 within each server 210 or 230 

other, or with one or more of the control servers 230, via include MSGH (message handling) routing 235 and MSGH 

either of the ethernets 220. In the event one of the ethernets buffers 225. The MSGH routing 235 contains routing 

220 is rendered inoperable, for any reason, in accordance information, including a table of names, machines (servers 

with the present invention communication, is automatically 210 and 230), addresses to use to send to each of the various 

switched to the other ethemet 220. servers 210 and 230, and information concerning what hosts 

FIG. 3 is a block diagram illustrating in greater detail the (servers) exist. The MSGH buffers 225 are utilized for 

system 200, and illustrating various apparatus embodiments storage of all messages transmitted and received by each 

in accordance with the present invention, namely, the van- 30 server 210 or 230. 

ous control servers 230^ and 230^^, and telecommunication FIG. 4 is a flow diagram illustrating the sending or 

servers 210^ and 210^^. As illustrated in FIG. 3, the various transmission portion of a protocol (method embodiment) in 

control servers 230^ and 230^, and the various telecommu- accordance with the present invention. Beginning with start 

nicalion servers 210^ and 210^, are all connected to each step 300, the message beings with the sender process, within 

other over the dual ethernets 220^ and 220^, These various 35 a processor 250, determining to send a message to a name 

servers 210 and 230 may be implemented utHizing any of any type, such as to a name "RCVR". Next, in step 305, 

preferred or desired servers known to those skilled in the art. the method determines whether the name is local, namely 

In the preferred embodiment, the servers employ a UNIX whether the name resides on the same server 210 or 230, or 

operating system, although other networking operating sys- whether the name resides on a remote (different) server 210 

tems may be utilized equivalently. 40 or 230. When the name is on the local server 210 or 230 in 

Cbntinuing to refer to FIG. 3, each of the various appa- step 305, the method finds the name in the MSGH routing 

ratus embodiments 210 and 230 include a processor 250 235 of the shared memory 240, step 310, and then delivers 

connected to a shared memory 240. Within each shared the message locally, step 315, utilizing the local delivery 

memory 240 is, first, a database or table of routing mechanism, such as UNIX IPC (interprocess 

information, referred to as message handling (MSGH) rout- 45 communication) or windows NT messaging, 

ing 235, and second, a message handhng (MSGH) buffer When the name is not on the local server 210 or 230 in 

225. Various processes are implemented within each pro- step 305, the method proceeds to step 320 and determines 

cesser 250 in accordance with the present invention, namely, whether the remote host (server 210 or 230) is active. In the 

a message handhng process 260 (referred to herein as preferred embodiment, this is determined by examining a 

MSGH 260), and a message handhng read process 270 50 predetermined bit which is set to either one or zero in the 

(MSGH READ PROC (or RPROC) 270). MSGH routing memory 235. When the remote host is not 

The messaging system utilized in the preferred embodi- active in step 320, the method checks if the sender process 

ments of the present invention are "name" or "mailbox** is the local message handling (MSGH) or message handling 

based systems, allowing each of the processors 250 to read processes (MSGH READ PROC), step 325, because in 

communicate with each other in a known or standard way, 55 accordance with the present invention, these processes arc 

without requiring any further knowledge or information allowed to send messages to inactive hosts. For example, the 

concerning any other processes implemented or running on method will periodically send a message to every host (such 

these processors 250. The messaging system allows various as a connectivity check message, discussed below with 

clusters of functionahty on separate computers/servers, and reference to FIG. 7), to determine whether it is active, and 

the processes (software) in each such computer/server are 60 preferably will receive a message back from each such 

not required know if any other process (software) is on the active host. If in step 325 the sending process is not message 

local computer/server or on a remote computer/server. As handling or message handling read process, then the method 

illustrated in FIG. 3, these various names (or mailboxes) are, returns an error message, step 370, and that portion of the 

in the control server 230^, a sender 255 and a receiver 245; method may end, return step 380. 

in the telecommunication server 210^, the name RCVR 265; 65 In the preferred embodiment, message sequence numbers 

and in the telecommunication server 210^, the name SNDR are maintained on a hosl-by-host basis. If a message is 

275. received having an out of sequence message number, the 
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receiving host knows that there is a missing message, ie., a include a message sequence number for the message being 

message it did not receive from the particular sending host sent, as discussed above, and will include reference to a 

having the missing message number. For example, if the sequence number for the last message which may have been 

receiving host has received messages 8 and 11 from a received, if any, from that specified host, as discussed in 

particular sending host, the receiving host automatically has 5 greater detail below. If the message were unable to be sent 

knowledge that messages 9 and 10 are missing. As a in step 365, such that the server operating system cannot 

consequence, for inactive remote hosts (step 320), when the transmit the message, then the message proceeds to step 370 

sending process is the message handling or message ban- and returns an error message. 

dling read processes (step 325), the method proceeds to step In the preferred embodiment, when a message is received 

330, setting a bit to reset the sequence numbers. Because the jq from a sending host, rather than transmitting a specific 

remote host was not active in step 320, setting a bit in the acknowledgment message back to the sending host, such an 

message calling for resetting of sequence numbers, in step acknowledgement is subsumed within another message to be 

330, will notify the remote host that in its resumption of an sent to that host. As mentioned above, that acknowledge- 

active state, it should resynchronize its sequence numbers naent is preferably a reference to the last sequence number 

for the particular sending server 210 or 230. received from that sending host. As a consequence, in 

When the remote host is active in step 320, or following accordance with the present invention, an acknowledgement 
step 330, the method proceeds to step 335 and determines is provided to the other host without utilizing a separate and 
whether the local process has an open connection, socket or additional acknowledgement message, which would other- 
port (on the server 210 or 230). Such an open connection is wise consume additional network resources and communi- 
usually a UDP port utilized to send messages. If the local 20 cation bandwidth. In order to keep the sending host within 
process does not have an open connection in step 335, the its message window, however, the receiving host maintains 
method proceeds to step 340 and creates such an open a count of the number of outstanding, unacknowledged 
connection. Following step 340, or following step 335 when messages received from that host. When the message was 
the process already has an open connection, the method sent successfully to a particular host in step 365, which 
proceeds to step 345 and obtains a message sequence 25 message now includes this acknowledgement of other mes- 
number from the MSGH routing 235 portion of shared sages which may have been received from the particular 
memory 240. host, the method proceeds to step 380 and clears this 

As mentioned above, in the preferred embodiment, unacknowledged message count and returns a success 

sequence numbers arc utilized to determine whether all message, step 380. In the preferred method embodiment, the 

messages transmitted have in fact been received by the 30 count of the number of messages received from a particular 

specified server 210 or 230. In addition, the preferred host, for which no messages or other form of acknowledge- 

method utilizes a "window" of a maximum number of ments have been transmitted back to that particular host, is 

messages transmitted to a specified remote host (server 210 maintained in the MSGH routing 235 of the shared memory 

or 230) that have not been acknowledged, as counted or 240. In step 380, that count is now cleared, because a 

determined by their sequence numbers. In the preferred 35 message is being sent to that specified host. Following steps 

embodiment, the message "window" is a maximum of 64 315, 370, or 380, the transmitting portion of the method may 

unacknowledged messages. As a consequence, following end, return step 385. 

obtaining a message sequence number in step 345, the FIG. 5 is a flow diagram illustrating a receive portion of 

method determines whether the obtained sequence number the protocol (method embodiment) in accordance with the 

is within the preferred window. If the sequence number is 40 present invention. Beginning with start step 400, the mes- 

not within the window in step 350, meaning that 64 (or some sage handling read process, on the remote server, reads the 

other predetermined number) messages have already been connection (UDP socket) on that remote server and receives 

sent for which no acknowledgements have been received, the message. The method then sets a connection counter, 

the method proceeds to step 370 and returns an error step 405, to track that the remote server has received a 

message. 45 message from the particular transmitting host on an active 

When the sequence number is within the window in step ethernet 220, indicating both an active ethernet 220 and an 

350, the method once again determines whether the remote active sending host. Next, in step 410, the message handling 

host is active, step 355, by examining whether the reset bit read process determines if the received message is out of 

to resynchronize sequence numbers has been set. If the sequence, step 410, as indicated by the sequence number of 

remote host is not active in step 355, the method proceeds 50 the received message. When the message is not out of 

to step 375 and resets the bit. Following step 375, or when sequence in step 410, the method proceeds to step 445. 

the remote host is active in step 355, the method proceeds to When the message is out of sequence in step 410, the method 

step 360. In step 360, the method allocates buffer space, and checks for certain types of messages which may have been 

copies the message (to be transmitted) into the designated transmitted and which, in the preferred embodiment, are 

transmit buffer, in the MSGH buffer 225 of the shared 55 allowed to be out of sequence. In these various cases 

memory 240, If such buffer space cannot be allocated in step discussed below, an out of sequence message is utilized to 

360, the method proceeds to step 370 and returns an error provide resynchronization between any two of the servers 

message, indicating that a suflScient number of messages are 210 and 230, determining that the sending and receiving 

outstanding to many other servers 210 and 230, such that servers have been trying to resume synchronization for some 

there is cunrently insufficient buffering capacity. When 60 time and have been unable to do so. For such 

buffer space has been allocated and the message copied into resynchronization, on an individual server-by-server basis, 

the buffer in step 360, the method sends the message to the sequence numbers will be reset to the sequence number of 

MSGH READ PROCESS on the remote server 210 or 230 the current message and all corresponding receive buffers 

over the active ethernet 220, which has been selected based will be cleared. 

upon the connectivity portion of the method discussed in 65 When the received message is out of sequence in step 410, 

greater detail below with reference to FIG. 7. The message the method first determines whether the received message is 

sent to the specified host, in the preferred embodiment, will a reject message, step 415. When the received message is a 
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reject message in step 415, the method will proceed to step receiving server, proceeding to step 470. When the message 

445. As discussed in greater detail below, reject messages is a reject message in step 465, indicating that the sending 

are utilized to indicate that a number of messages have been host has a message outstanding which it needs to receive, the 

missed or lost, and should be retransmitted. method also proceeds to step 470, to ultimately resend the 

When the received message is out ofsequence in step 410 s requested outstanding messages (in steps 520 and 525, 

and when the received message is not a reject message in discussed below). When the message is not in sequence in 

step 415, the method will determine whether any of three step 460, and when the received message is not a reject 

cases or situations exists which would indicate that resyn- message in step 465, the method proceeds to step 530 to 

chfonization should proceed. First, in step 420, the method provide storage for the received message and to enter a reject 

determines whether the reset bit is set in the received state, in order to subsequently transmit a reject message to 

message, indicating that the receiving host should resyn- the sender, to indicate the existence of one or more out- 

chronize with the sending host. When such a reset bit is set standing (missed) messages. 

in step 420, the method proceeds to resynchronize in step When the message is not in sequence in step 460 and is 
435, discussed below. When the reset bit is not set in the not a reject message in step 465, the method proceeds to step 
received message in step 420, the method proceeds to step 530 and determines if the received message is within the 
425, and determines whether the sending host is (was) receive window. In the preferred embodiment, there are 128 
inactive. If the sending host is (was) inactive in step 425, the possible sequence numbers utilized. At any one time, the 
method also proceeds to step 435. When the sending host is receiving server should only receive messages having 
active in step 425, the method determines whether the sequence number within a range or window of 64 of such 
receiving server has already sent a maximum number of sequence numbers. If the sequence number of the received 
reject messages to the sending host, step 430. Such a message is not within the window in step 530, that me.ssage 
maximum number of reject messages indicates that out of is ignored, based upon the presumption that the currently 
sequence messages have continued to be received, even received message is a retransmission or a multiple transmis- 
though reject messages have been sent on numerous occa- sion of a message which had already been received previ- 
sions. When a maximum number of reject messages have ously. For example, a reject message may have been sent 
been sent in step 430, the method avoids any further previously, followed by a retransmission, and under certain 
potential delay, allows for a limited degree of unreliability, circumstances, there may be multiple such retransmissions, 
by determining that all such older messages are now ren- As a consequence, when the sequence number of the 
dered irrelevant due to the passage of time, and may now be received message is not within the receive window in step 
ignored. 3q 530, the received message is ignored, and the method may 

As a consequence, for an out of sequence received end, return step 555. 

message, when the maximum number of reject messages When the sequence number of the received message is 

have been sent (in step 430), or when the sending host is within the receive sequence window, in step 530, and, as 

inactive (in step 425), or when the reset bit has been set in discussed above, is not in sequence (step 460), the received 

the received message (in step 420), the method proceeds to 35 message is buffered in a receive buffer, step 535, such as 

step 435. In each of these three cases, the method will MSGH buffer 225. The method then determines whether the 

resynchronize the protocol with the sending host by resetting receiving host is already in a reject state for that particular 

the receive sequence number to the particular number con- sending host. If the receiving server is already in a reject 

tained in the message received currently, step 435. Follow- state for the particular sending host, in the preferred 

ing step 435, in step 440, the method also clears the receive 40 embodiment, the method avoids any continual or additional 

message buffers for the particular sending host. Following sending of reject messages and as a consequence, the 

step 440, the method proceeds to step 445. method may end, retum step 555. When the receiving host 

When a received message is in sequence in step 410, is not already in a reject state for the particular sending host 

when a reject message has been received in step 425, or in step 540, the method proceeds to step 545 and immedi- 

foUowing steps 430 or 440, the method proceeds to step 445 45 ately sends a reject message. Such a reject message includes 

and increments the count of received messages from the an indicator of the number of outstanding messages and the 

particular sending host which have not been acknowledged sequence number of the message just received. For example, 

by the receiving server. As previously discussed, this count if the sequence number of the received message is 89, and 

is reset to zero whenever a message is transmitted back to the last previous message has a sequence number of 86, the 

the particular sending host. Such a message will indicate the 50 reject message will include an indication that 89 was the last 

last message received, thereby having a dual role as both an sequence number received, and that two messages are 

acknowledgement and as an independent message. In the missing, namely, 87 and 88. Following sending of such a 

event that such independent messages which also contain reject message, the receiving server enters the reject state for 

such an acknowledgement have not been transmitted for the particular sending host, step 550, as discussed in greater 

some time, such that the unacknowledged count is greater ss detail below with respect to FIG, 6, and this portion of the 

than a predetermined number, such as 8, in step 450, the receiving method may end, return step 555. 

method will proceed to step 455 and generate an otherwise When the message received is in sequence in step 460, or 

empty message to the sender as an acknowledgement. When is a reject message in step 465, the method proceeds to step 

the unacknowledged count is not greater than such a pre- 470, and examines the received message. More particularly, 

determined number in step 450, the method proceeds to step 60 utilizing the acknowledgement sequence number contained 

460. in the received message, as discussed above, which indicates 

In steps 460 and 465, the method determines, without the that the particular sending host itself has properly received 
other conditions of steps 420, 425 and 430, whether the messages previously transmitted from the server 210 or 230, 
received message is in sequence, step 460, or whether the the method clears any transmit message buffers of the 
received message is a reject message, step 465. As discussed 65 MSGH buffer 225 (in the shared memory 240) which had 
in greater detail below, when the message is in sequence in been storing (for possible retransmission) previously trans- 
step 460, the message will be delivered locally within the mitted messages, through that sequence number. The send- 
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ing host is then maintained or reset to an active state, step with the next message, step 630. The protocol is reset to 
475, and the ethemet connectivity counter is maintained or accept the next message as having a valid receive sequence 
reset, indicating that a valid message may be received from number, step 630, and all receive buffers are cleared, step 

the sending host over the particular ethemet connection 635. Under these circumstances, the sending and receiving 

(220^ or 220^), step 480 (and discussed in greater detail 5 servers have been out of synchrony for a predetermined 
below with reference to FIG. 7). Next, for reject messages maximum period of time. To avoid any further delays, in 

in step 485, the method proceeds to step 520, while for in accordance with the present invention, the. various servers 

sequence messages which are not reject messages in step then resynchronize by both designating that the next mes- 

485, the method proceeds to step 490. sage automatically has a valid receive sequence number, and 

For reject messages in step 485, the method then deter- clearing or freeing their receive buffers. Following step 625 

mines the sequence number (of the last message received) or 635, the reject state portion of the method may end, return 

and the number of outstanding messages, as indicated in the step 640. 

received message, step 520. The method then resends the FIG. 7 is a flow diagram illustrating a connectivity state 

requested outstanding messages, step 525. portion of the protocol (method embodiment) in accordance 

For in sequence messages which are not reject messages 55 with the present invention. This connectivity state part of the 

instep 485, the method proceeds to step 490 and delivers the protocol is utilized to select or switch between ethernets 

received message to the local process having the designated 220^ and 220^, and to determine whether a given server 210 

name, utilizing the server operating system (precisely as in or 230 is active or inactive. As discussed in greater detail 

step 315 with regard to local sending of messages). Follow- below, the method determines whether a message has been 

ing step 490, the method updates the received message count 20 received from a given server within a predetermined period 

from the particular sending host, incrementing it by one, step of time or, in other terms, whether the given server has been 

495. The method then examines the receive buffers, to silent for a predetermined maximum period of time. In the 

determine whether there are previously out of sequence preferred embodiment, such time periods are determined 

messages, which are now are in sequence messages, being utilizing a counter referred to as a connectivity count, such 

stored in the receive buffer, step 500. When there are in 25 connectivity count is increased when no messages 

sequence messages stored in the receive buffer in step 500, have been received during a given interval. If the given 

the method then delivers all in sequence messages and clears server has been silent during the interval, the method may 

thoseportionsof the receive buffer, step 505. When there are attempt to communicate with that server and, if 

no additional remaining messages in the receive buffer in unsuccessful, switch ethemet connections, and try again 

step 510, the method clears the reject state, step 515, as the 30 during the next interval. If the given server has not 

sending and receiving servers are in synchrony and caught responded to these communications over either ethemet and 

up with each other Following step 515, or when there are thereby has continued to be silent for the predetermined 

remaining messages in the receive buffer in step 510, or maximum period of time (as determined by the connectivity 

when there are no in sequence messages in the receive buffer count reaching a predetermined maximum value), the given 

in step 500, the receive portion of the method may end, 35 server is determined to be nonfunctional and is given an 

return step 555. inactive status. 

FIG, 6 is a flow diagram illustrating a reject state portion Beginning with start step 700, the method enters a con- 

of the protocol (method embodiment) in accordance with the nectivity state at predetermined intervals. In the preferred 

present invention. The reject state is entered, step 600, from embodiment, the connectivity state portion of the protocol is 

step 550 discussed above. In the reject state, at predetcr- 40 executed by the message handling read process 270 in a 

mined intervals, such as every 300 ms in the preferred processor 250. The MSGH read process 270 transmits an 

embodiment, the method determines, for each sending internal message to the MSGH 260 indicating, for each 

server, whether the server is in a reject state for that server (host), if a message has been received from that server 

particular sending server (indicating one or more out of (host), step 705. The MSGH 260 receives this intemal 

sequence messages received from that particular sending 45 message from the MSGH read process 270, step 710 and, as 

server). The method first determines whether it has been in discussed in greater detail below, loops through the message 

a reject state for the particular sending host for more than on a per server basis, examining the message as pertaining 

one interval, as the reject state was immediately entered to each given or specific host. 

upon completion of step 550, and additional reject messages The method first determines whether a message has been 

do not need to be sent without an intervening period of time, 50 received from a given host during the predetermined 

When the receiving host has been in a reject state for a interval, step 715. If a message has been received from that 

particular host for more than one interval in step 605, the given host in step 715, the method clears the connectivity 

method determines whether a predetermined maximum count (the silent time parameter), as the given host has not 

number of reject messages have been sent, step 610. In the been silent during the interval, step 720, and sets the status 

preferred embodiment, in which rcsynchronization should ss of the given host to an active status, step 725. If a message 

occur within approximately 2 seconds or less, a maximum has not been received from the given host in step 715, the 

number of reject messages is generaUy 7 or 8. When a method determines in step 730 if the particular host has 

maximum number of reject messages have not been sent in exceeded its maximum time of silence, as indicated by its 

step 610, the method proceeds to step 615 and determines connectivity count reaching a predetermined maximum 

the number of messages outstanding. ITie method then 60 value. If in step 730 the maximum silent time has been 

transmits a reject message with an indicator of the current exceeded, the method proceeds to step 735 and sets the 

number of outstanding messages and the sequence number status of the given host to an inactive status, step 735, 

of the last received message. The method then increments indicating that the particular host may be inoperative. The 

the count of the number of reject messages, step 625, and the method then clears all transmit and receive buffers pertain- 

reject slate portion of the method may end, return step 650. 65 ing to that particular host, step 740, and proceeds to step 760. 

When the maximum number of reject messages have been When a message has not been received from the given 

sent in step 610, the method will resynchronize the protocol host (step 715), and when the given host has not exceeded 
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its maximum silent time (step 730), the method transmits a 
connectivity check message (or connect message) to the 
given host, step 745. In the preferred embodiment, this 
connectivity check message is a particular message request- 
ing the given host to transmit any kind or type of message $ 
back to the processing server. If the given host does not 
respond to this connectivity check message, it may be 
presumed either that the given host has become inoperative, 
or that the ethemet connection may have become inopera- 
tive. Following step 745, the method determines whether 
this is the first connectivity check message to the given host, 
step 750. When the connectivity check message is the first 
message sent to the given host in step 750, the method may 
proceed to step 760. 

A significant feature of the various embodiments of the 
present invention is the ability to automatically detect vari- 
ous hardware failures, such as the loss of one of the ethemets 
220^ or 220^, and to automatically re-route traffic onto the 
other, remaining ethemet 220^ or 220^, respectively. When 
the connectivity message is not the first connectivity mes- 
sage sent to the given host in step 750, the method will 
switch the ethernet connection utilized to communicate with 
the given host, selecting the other (alternative) network as 
active, step 755, i.e., switching or toggling between ethernet 
220^ and ethemet 220. In this way, so long as one of the two 
ethemets 220 is operative, a server 210 or 230 connected to 
that ethernet will receive a connectivity check message and, 
if operative, respond to the message and retain its active 
status in accordance with the present invention. In addition, 
in the event that one of the two ethemets 220 is disabled, 
utilizing this connectivity state routine in the preferred 
embodiment, each server 210 or 230 will automatically 
switch to the remaining active ethernet. As a consequence, 
in accordance with the present invention, a hardware failure 
will automatically be detected, and traffic will be corre- 
spondingly re-routed. 

Following step 725, step 740 and step 755, the method 
determines if additional hosts should be examined, step 760. 
When there are additional hosts for which connectivity is to 
be checked in step 760, the method returns to step 715. 
When there are no more remaining hosts requiring connec- 
tivity checks, in step 760, the method may end, return step 
765. 

As may be apparent from the above discussion, there arc 
numerous advantages of the various embodiments of the 45 
present invention. As mentioned above, hardware failures 
are automatically detected, such as a loss of an ethemet, with 
traffic correspondingly re-routed. 

Another one of the most significant advantages of the 
present invention is the intermediate level of reliability and 50 
low delay characteristics provided by the various 
embodiments, which are especially suited for real-time 
applications such as internet telephony. Resynchronizations 
may occur to avoid undue delays in message transmission 
and reception, while message buffering reduces message 55 
loss. Such resynchronization, including clearing buffers and 
resetting sequence numbers, occurs while the protocol is 
maintained as up and valid, with ongoing communication, 
rather than the prior art loss of the connection. 

In addition, the various embodiments of the invention 60 
utilize a connectionless, semi -reliable message transport 
while simultaneously maintaining the higher level of reli- 
ability associated with connection oriented protocols. Unlike 
connectionless protocols, however, in the preferred 
embodiment, the sender will be notified of undeliverable 65 
messages, and the protocol will maximize accurate delivery 
within its time constraints. 
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From the foregoing, it will be observed that numerous 
variations and modifications may be effected without depart- 
ing from the spirit and scope of the novel concept of the 
invention. It is to be understood that no limitation with 
respect to the specific methods and apparatus illustrated 
herein is intended or should be inferred. It is, of course, 
intended to cover by the appended claims all such modifi- 
cations as fall within the scope of the claims. 

We claim: 

1. A method for an intermediate reliability protocol for 
network message transmission and reception, the method 
comprising: 

(a) receiving a message; 

(b) when the received message has a sequence number 
which is out of sequence, determining whether a reset 
bit is set and, when the reset bit is set, resynchronizing 
to the received message; 

(c) when the received message has a sequence number 
which is out of sequence, determining whether the 
transmitting host is inactive and, when the transmitting 
host is inactive, resynchronizing to the received mes- 
sage; and 

(d) when the received message has a sequence number 
which is out of sequence, determining whether a pre- 
determined number of transmit reject messages have 
been transmitted and, when the predetermined number 
of transmit reject messages have been transmitted, 
resynchronizing to the received message. 

2. The method of claim 1, further comprising: 

(e) when the received message is a received reject 
message, retransmitting an outstanding transmitted 
message. 

3. The method of claim 2, wherein the received reject 
message designates a sequence number of a last received 
message and designates a number of outstanding messages. 

4. The method of claim 1, wherein resynchronizing to the 
received message further comprises resynchronizing to the 
sequence number of the received message. 

5. The method of claim 1, wherein resynchronizing to the 
received message further comprises clearing receive buffers. 

6. The method of claim 1, wherein the resynchronizing is 
limited to a designated transmitting server of a plurality of 
servers. 

7. The method of claim 1, further comprising: 

when the received message has a sequence number which 
is out of sequence, transmitting a transmit reject mes- 
sage without resynchronizing. 

8. The method of claim 7, wherein the transmit reject 
message includes a designation of a number of messages 
outstanding. 

9. The method of claim 7, further comprising: 
incrementing a count of transmit reject messages. 

10. The method of claim 9, further comprising: 

when the count of transmit reject message is equal to the 
predetermined number of transmit reject messages, 
accepting a next received message as having a valid 
sequence number and resynchronizing to the next 
received message. 

U. The method of claim 1, further comprising: 

when the received message has a sequence number which 
is out of sequence, buffering the received message. 

12. The method of claim 1, further comprising; 

when the received message has a sequence number which 
is out of sequence, and when the sequence number is 
not within a receive sequence window, ignoring the 
received message. 
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13. The method of claim 1, further comprising: ratus coupleable to a network for message transmission and 
when the received message has a sequence number which reception, the apparatus comprising; 

is in sequence, delivering the received message to a a shared memory; and 

designated local process. a processor coupled to the shared memory, wherein the 

14. The method of claim 1, further comprising: 5 processor, when operative, includes program instruc- 
when the received message has a sequence number which ^^n^ to receive a message; when the received message 

is in sequence, clearing transmit buffers of any mes- ^ sequence number which is out of sequence, the 

sages through an acknowledgement sequence number. processor having further instructions to determine 

15. The method of claim 1, further comprising: ^ ^^^et bit is set and, when the reset bit is set, 

when the received message has a sequence number which ^ resynchronize to the received message; when the 

is in sequence, setUng a status of a transmitting server °^^^f 8^ ^ ^^^^^^'^^ "^^'f ^f.^^^ 

as active ' = = of sequence, the processor having further instructions 

16*The method of claim 1, forther comprising: to determine whether the transmitting host is inactive 

. ^ ' .... and, when the transmitting host is uiactive, to resyn- 

when the received message has a sequence number which j; ^^^^^j^g ^^ ^^^^ ^^^^j^^j ^^^^ 

IS in sequence, designating a network connecUon as received message has a sequence number which is out 

aolive. , , . , . ^ . , . . of sequence, the processor having further instructions 

17. The method of clann 1, further composing: determine whether a predetennined number of trans- 
when the received message has a sequence number which jj,it reject messages have been transmitted and, when 

is in sequence, delivering to a local process a previ- 20 the predetermined number of transmit reject messages 

ously received message having a sequence number have been transmitted, to resynchronize to the received 

which is now in sequence. message. 

18. The method of claim 17, further comprising: 30. The apparatus of claim 29, wherein the processor has 
clearing a receive buffer of the previously received mes- further instructions, when the received message is a received 

sage. 25 reject message, to retransmit an outstanding transmitted 

19. The method of claim 1, further comprising: message. 

when the received message has a sequence number which 31. The apparatus of claim 30, wherein the received reject 

is in sequence, incrementing a count of received unac- message designates a sequence number of a last received 

knowledged messages. message and designates a number of outstanding messages. 

20. The method of claim 19, further comprising: 30 32. The apparatus of claim 29, wherein the processor has 
when the count of received unacknowledged messages is further instructions to resynchronize to the sequence number 

greater than a predetermined number of received unac- of the received message. 

knowledged messages, transmitting a message as an ^3. The apparams of claim 29, wherein the processor has 

acknowledgement. further instmctions to clear receive buffers in the shared 

21. The method of claim 1, farther comprising: 35 memory during resynchronization. 

transmitting a message having a next sequence number of ^4. The apparatus of claim 29, wherein the processor has 

a plurality of sequence numbers. ^^^^^^ instructions to limit resynchronization to a desig- 

22. The method of claim 21, wheiehi the transmitted ^^^ed transmitting server of a plurality of servers, 
message further contains an acknowledgement of a sequence ^ apparatus of claim 29, wherem the processor has 
number of a most recently received message. ^° instructions when the received message has a 

23. The method of claim 21, wherein the transmitted sequence number which is out of sequence, to transmit a 
message further contains a reset bit which is set. transmit reject message without resynchronizing. 

24. The method of claim 1, further comprising: apparatus of claim 35, wherem the transmit reject 
. , ^ L - J f J * J message includes a designation of a number of messages 

when a message has not been received from a designated outstandin 

server of a plurality of servers during a first predeter- -^^t- ^ ^i-ic u - .i. t. 

. • J c * -^^^ ^ * -* 37, The apparatus of claim 35, wherein the processor has 

mined period of time, transmittmg a first connectivity ^ ^. ^ . • 1 ^ • . 

.. J ® a * 1 further mstructions to increment a count ol transmit reject 
message to the designated server over a first network. 

25. The method of claim 24, further comprising: , r 1 • u • u 

' f to 3g -Qjg apparatus of claim 37, wherein the processor has 

when a response message has not been received from the ^^^^^^ instructions, when the count of transmit reject mes- 

designated server during a second predetermined sages is equal to the predetermined number of transmit reject 

period of time, transmitting a second connectivity messages, to accepting a next received message as having a 

message to the designated server over a second net- ^^^^^ sequence number and to resynchronize to the next 

. . received message. 

26. The method of claun 25, further comprismg: 55 39 apparatus of claim 29, wherein the processor has 
when a response message has not been received from the further instructions, when the received message has a 

designated server during a third predetermined period sequence number which is out of sequence, to buffer the 

of time, setting a staUis of the designated server as received message in the shared memory. 

inactive. 40. The apparatus of claim 29, wherein the processor has 

27. The method of claim 26, further comprising: further instructions, when the received message has a 
clearing all transmit buffers and all receive buffers per- sequence number which is out of sequence, and when the 

taining to the designated server. sequence number is not within a receive sequence window, 

28. The method of claim^ 1, further comprising: to ignore the received message. 

maintaining a valid protocol state during resynchroniza- 41. The apparatus of claim 29, wherein the processor has 
tion. 65 further instructions, when the received message has a 

29. An apparatus for an intermediate reliability protocol sequence number which is in sequence, to deliver the 
for network message transmission and reception, the appa- received message to a designated local process. 
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42. The apparatus of claim 29, wherein the processor has 
further instructions, when the received message has a 
sequence number which is in sequence, to clear transmit 
buffers, in the shared memory, of any messages through an 
acknowledgement sequence number. s 

43. The apparatus of claim 29, wherein the processor has 
further instructions, when the received message has a 
sequence number which is in sequence, to set a status of a 
transmitting server as active. 

44. The apparatus of claim 29, wherein the processor has lo 
further instructions, when the received message has a 
sequence number which is in sequence, to designate a 
network connection as active. 

45. The apparatus of claim 29, wherein the processor has 
further instructions, when the received message has a is 
sequence number which is in sequence, to deliver to a local 
process a previously received message having a sequence 
number which is now in sequence. 

46. The apparatus of claim 45, wherein the processor has 
further instructions to clear a receive buffer in the shared 20 
memory of the previously received message. 

47. The apparatus of claim 29, wherein the processor has 
further instructions, when the received message has a 
sequence number which is in sequence, to increment a count 

of received unacknowledged messages. 25 

48. The apparatus of claim 47, wherein the processor has 
further instructions, when the count of received unacknowl- 
edged messages is greater than a predetermined number of 
received unacknowledged messages, to transmit a message 

as an acknowledgement. 30 

49. The apparatus of claim 29, wherein the processor has 
further in instructions to transmit a message having a next 
sequence number of a plurality of sequence numbers. 

50. The apparatus of claim 49, wherein the transmitted 
message further contains an acknowledgement of a sequence 35 
number of a most recently received message. 

51. The apparatus of claim 49, wherein the transmitted 
message further contains a reset bit which is set. 

52. The apparatus of claim 29, wherein the processor has 
further instmctions, when a message has not been received 40 
from a designated server of a plurality of servers during a 
first predetermined period of time, to transmit a first con- 
nectivity message to the designated server over a first 
network. 

53. The apparatus of claim 52, wherein the processor has 45 
further instructions, when a response message has not been 
received from the designated server during a second prede- 
termined period of time, to transmit a second connectivity 
message to the designated server over a second network. 

54. The apparatus of claim 53, wherein the processor has 50 
further instructions, when a response message has not been 
received from the designated server during a third predeter- 
mined period of time, to set a status of the designated server 

as inactive. 

55. The apparatus of claim 54, wherein the processor has 55 
further instructions to clear all transmit buffers and all 
receive buffers in the shared memory pertaining to the 
designated server. 

56. The apparatus of claim 29, wherein the processor has 
further instmctions to maintain a valid protocol state during 60 
resynchronization . 

57. A system for an intermediate rehability protocol for 
network message transmission and reception, the system 
comprising: 

a first server, wherein the first server, when operative, 65 
includes program instructions to transmit a message; 
and 
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a second server coupled to the first server over a plurality 
of networks, wherein the second server, when 
operative, includes program instructions to receive the 
message; when the received message has a sequence 
number which is out of sequence, the second server 
having further instructions to determine whether a reset 
bit is set and, when the reset bit is set, to resynchronize 
to the received message; when the received message 
has a sequence number which is out of sequence, the 
second server having further instructions to determine 
whether the first server is inactive and, when the first 
server is inactive, to resynchronize to the received 
message; and when the received message has a 
sequence number which is out of sequence, the second 
server having further instructions to determine whether 
a predetermined number of transmit reject messages 
have been transmitted to the first server and, when the 
predetermined number of transmit reject messages 
have been transmitted to the first server, to resynchro- 
nize to the received message. 

58. The system of claim 57, wherein the second server has 
further instructions, when the received message is a received 
reject message, to retransmit an outstanding transmitted 
message to the first server. 

59. The system of claim 58, wherein the received reject 
message designates a sequence number of a last received 
message and designates a number of outstanding messages. 

60. The system of claim 57, wherein the second server has 
further instructions to resynchronize to the sequence number 
of the received message. 

61. The system of claim 57, wherein the second server has 
further instructioas to clear receive buffers in a shared 
memory of the second server during resynchronization. 

62. The system of claim 57, further comprising a plurality 
of servers coupled to the first server and to the second server 
over the plurality or networks, and wherein the second 
server has further instructions to limit resynchronization to 
a designated transmitting server of the pluraUty of servers. 

63. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is out of sequence, to transmit a 
U-ansmit reject message to the first server without resynchro- 
nizing. 

64. The system of claim 63, wherein the transmit reject 
message includes a designation of a number of messages 
outstanding. 

65. The system of claim 63, wherein the second server has 
further instructions to increment a couint of transmit reject 
messages. 

66. The system of claim 65, wherein the second server has 
further instructions, when the count of transmit reject mes- 
sages is equal to the predetermined number of transmit reject 
messages, to accepting a next received message as having a 
valid sequence number and to resynchronize to the next 
received message. 

67. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is out of sequence, to buffer the 
received message in a shared memory of the second server. 

68. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is out of sequence, and when the 
sequence number is not within a receive sequerice window, 
to ignore the received message. 

69. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is in sequence, to deliver the 
received message to a designated local process within the 
second server. 
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70. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is in sequence, to clear transmit 
buffers, in a shared memory of the second server, of any 
messages through an acknowledgement sequence number. 

71. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number wliich is in sequence, to set a status of the 
first server as active. 

72. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is in sequence, to designate a 
network of the plurality of networks as active. 

73. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is in sequence, to deliver to a local 
process within the second server a previously received 
message having a sequence number which is now in 
sequence. 

74. The system of claim 45, wherein the second server has 
further instructions to clear a receive buffer in a shared 
memory of the second server of the previously received 
message. 

75. The system of claim 57, wherein the second server has 
further instructions, when the received message has a 
sequence number which is in sequence, to increment a count 
of received unacknowledged messages, 

76. The system of claim 57, wherein the second server has 
further instructions, when the count of received unacknowl- 
edged messages is greater than a predetermined number of 
received unacknowledged messages, to transmit a message 
to the first server as an acknowledgement. 

77. The system of claim 57, wherein the second server has 
further instructions to transmit a message to the first server 
having a next sequence number of a plurality of sequence 
numbers. 

78. The system of claim 77, wherein the transmitted 
message further contains an acknowledgement of a sequence 
number of a most recently received message. 

79. The system of claim 77, wherein the transmitted 
message further contains a reset bit which is set. 



80. TTie system of claim 57, wherein the second server has message. 



a plurality of servers, each server of the plurality of 
servers coupled to each other server of the plurality of 
servers over the plurality of networks, the plurality of 
servers including a first server and a second server, 
wherein the first server, when operative, includes pro- 
gram instructions to transmit a message; and wherein 
the second server, when operative, includes program 
instmctions to receive the message; when the received 
message has a sequence number which is out of • 
sequence, the second server having further instructions 
to determine whether a reset bit is set and, when the 
reset bit is set, to resynchronize to the received mes- 
sage; when the received message has a sequence num- 
ber which is out of sequence, the second server having 
further instructions to determine whether the first server 
is inactive and, when the first server is inactive, to 
resynchronize to the received message; and when the 
received message has a sequence number which is out 
of sequence, the second server having further instruc- 
tions to detennine whether a predetermined ntmiber of 
transmit reject messages have been transmitted to the 
first server and, when the predetermined number of 
transmit reject messages have been transmitted to the 
first server, to resynchronize to the received message. 

87. The system of claim 86, wherein the second server has 
further instructions, when the received message is a received 
reject message, to retransmit an outstanding transmitted 
message to the first server. 

88. The system of claim 86, wherein the resynchroniza- 
tion to the received message includes resynchronization to 

30 the sequence number of the received message and clearing 
receive buffers in a shared memory of the second server. 

89. The system of claim 86, wherein the second server has 
further instructions, when the received message has a 
sequence number which is out of sequence, to transmit a 
transmit reject message to the first server without resynchro- 
nizing and to increment a count of transmit reject messages; 
and when the count of transmit reject messages is equal to 
the predetermined number of transmit reject messages, to 
accepting a next received message as having a valid 
sequence number and to resynchronize to the next received 
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further instructions, when a message has not been received 
from the first server during a first predetermined period of 
time, to transmit a first connectivity message to the first 
server over a first network of the plurality of networks. 

81. The system of claim 80, wherein the second server has 
further instructions, when a response message has not been 
received from the first server during a second predetermined 
period of time, to transmit a second connectivity message to 
the first server over a second network of the plurality of 
networks. 

82. The system of claim 81, wherein the second server has 
further instructions, when a response message has not been 
received from the first server during a third predetermined 
period of time, to set a status of the first server as inactive. 

83. The system of claim 82, wherein the second server has 
further instructions to clear all transmit buffers and aU 
receive buffers, in a shared memory of the second server, 
pertaining to the first server. 

84. The system of claim 57, wherein the second server has 
further instmctions to maintain a valid protocol state with 
the first server during resynchronization. 

85. The system of claim 57 wherein the plurality of 
networks are two ethemets. 

86. A system for an intermediate reliability protocol for 
network message transmission and reception, the system 
comprising: 

a plurality of networks; and 
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90. The system of claim 86, wherein the second server has 
further instructions, when the received message has a 
sequence number which is out of sequence, to buffer the 
received message in a shared memory of the second server. 

91. The system of claim 86, wherein the second server has 
further instructions, when a message has not been received 
from the first server during a first predetermined period of 
time, to transmit a first connectivity message to the first 
server over a first network of the plurality of networks. 

92. The system of claim 91, wherein the second server has 
further instructions, when a response message has not been 
received from the first server during a second predetermined 
period of time, to transmit a second connectivity message to 
the first server over a second network of the plurality of 
networks. 

93. The system of claim 92, wherein the second server has 
further instructions, when a response message has not been 
received from the first server during a third predetermined 
period of time, to set a status of the first server as inactive 
and 10 clear all transmit buffers and all receive buffers, in a 
shared memory of the second server, pertaining to the first 
server. 

94. The system of claim 86, wherein the second server has 
further instructions to maintain a valid protocol state with 
the first server during resynchronization. 
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